laya: add a reproduction command for every Apple Silicon benchmark number - #67

Purpose

Follow-ups to #30:

1. Every performance number in the Apple Silicon recipe now has a command that reproduces it. Laya on Apple Silicon: worker, benchmarks and recipe #30
   shipped scripts for the main comparisons, but several numbers in the recipe came from one-off probes
   that were not in the repository: requests after an idle gap, the cost of new input lengths and the
   memory they add, a checkpoint loaded while serving, and the CPU fallback. The benchmark README now
   has a table from each recipe claim to the command behind it, and the missing pieces are added:

   • paired.py --gap SECONDS (each request after that much idle, on a fresh connection) and --only;
   • lengths.py: first request of new input lengths and the footprint they add, for one or two flag sets;
   • late_load.py: a checkpoint loaded while serving, its first request directly and through the frontend;
   • fallback.py: Laya's fallback to the CPU under a lowered MPS memory limit;
   • release.py: the memory torch.mps.empty_cache() gives back after many new lengths, and whether
     those lengths are cold again afterwards. It prepares the model with the worker's own startup
     (build_app: options and warmup), exits if the model is not on MPS, walks lengths with
     lengths.py's walk, and reads each footprint --settle seconds after a release;
   • a loop of fresh starts for the first request after ready, alternating the worker with plain
     laya-serve.

   late_load.py, fallback.py and release.py refuse a measured run on battery or under load like
   the other scripts (--feasibility runs anyway); the check and the workload reader are now shared
   helpers in env.py.

   Two statements had no command behind them and were changed instead: the recipe no longer gives
   numbers for keeping the GPU busy between requests (it only says the worker does not do this), and
   the ~70 s late load with --compile could not be reproduced (19–22 s alone, 17 s with a second
   worker holding memory on the same GPU), so the recipe gives no number for a load past the frontend's
   60 s and only says what happens then. The recipe's count of every length up to the window is now the
   454 that the full-window command reaches (it said 477, from an earlier probe with shorter inputs).

   Each is an A/B where the claim is a comparison (with the options against without, or a worker against
   plain laya-serve). A rerun gives other numbers on another Mac or under other load; the comparison is
   what should carry over. Rerunning everything on the M1 Pro changed these recipe statements (see Test
   Result): the late load with --compile (19–22 s; no number past 60 s), the CPU fallback request
   (30–73 s), every length up to the window (454 lengths, 5.2 GB with the options, 3.7 GB without),
   what a release gives back (back to about 2.95 GB), and plain laya-serve's first request after ready
   (0.7–1.1 s then, 0.2–0.4 s in seven later fresh starts, cause not known).

2. Readiness contract test (flaky on an M4 in the last review): it now checks that the first request
   after ready succeeds with a valid answer, without a latency bound. That latency depends on how long
   the GPU has been idle and on the Mac (an M5 answered a first request without any warmup in 132–143 ms),
   so it stays in the benchmarks. That the warmup ran before ready is still tested.

3. ruff format drift: the Laya files are formatted with ruff 0.16.10 defaults (88 columns, as the rest
   of the repository; the first commit is formatting only, with every file's syntax tree unchanged), and
   requirements-mps.txt pins ruff, pytest and httpx2. Comments that the formatter had pushed onto
   closing brackets are back above their statements, so the two noqa: SIM115 suppress again.

4. Stale docstring in tests/laya/test_worker.py; the reviewer's M4 is listed in the recipe.

No change to the worker's runtime code. A CI job for tests/laya was suggested in the review; happy to
add one in a separate PR if you want it.

Test Plan

System1-Omni Version / Commit: 62dc52a on top of 58b8cbe

• Every reproduction command in the benchmark README run at least once on the M1 Pro.
• ruff format --check and ruff check --select E4,E7,E9,F on the Laya files, ruff 0.16.10.
• PYTHONPATH=src python -m pytest tests/laya, and with LAYA_CONTRACT=1; contract tests on MPS
  without and with --compile --weights fp16.
• The documented-commands test also checks the inline commands of the reproduction table against each
  script's flags (a misspelled flag fails it).
• mkdocs build --strict.

Test Result

All reruns on the M1 Pro (16 GB). None was on an idle machine on mains power, so they were run as
feasibility; what each shows is that the command runs and whether the recipe's effect is there. The
conditions column says which session a row comes from.

Checks: ruff format and check clean; 98 unit tests passed, 118 with LAYA_CONTRACT=1; contract on MPS
20/20 plain and with the options; strict docs build passes.

Self-review

Several self-review passes ran before this description; each issue below was reproduced (a test that
failed, or a rerun) before it was fixed.

• lengths.py now skips the lengths the warmup ran (read back from the worker) and stops at the window;
  the full-window walk covers 454 lengths, 57–512 tokens.

• late_load.py waits up to --timeout, follows up a load cut off by a 504 or a timeout only if the
  checkpoint became resident, refuses a --late the worker already serves, and documents every field.

• release.py prepares the model the way the worker does, exits off MPS, keeps the traceback of other
  failures, reads W1 by id, and walks lengths with lengths.py.

• Every script that measures refuses a noisy machine; fallback.py says why its memory probe failed.

• Two measurements did not hold and are not in the recipe: a release giving back "about half" and then
  "about 60%" came from a starting footprint that varies by a few hundred MB between processes and from
  reading the footprint before the release had landed (release.py now reads --settle seconds later);
  a torch.mps.synchronize() before the release made no difference in an A/B (it waits 0.004 ms after
  a request). The ~70 s late load could not be reproduced, with or without a second worker.

• I have reviewed the full diff and addressed the issues I found.

• I have checked that the change follows the project's architecture and stays focused on the stated purpose.

• I have run the checks appropriate to this change and reported commands, results, and anything I could not verify above.

• I have checked that the PR description, documentation, and any accuracy or performance claims match the implementation and available evidence.